IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Application of David Paul Limont et al. Art Unit 2444 

Serial No. 10/719,866 
Filed November 21, 2003 
Confirmation No. 3063 

For METHOD AND COMPUTER PROGRAM PRODUCT TO PROVIDE SYNC 

NOTIFICATIONS TO CLIENT DEVICES 
Examiner Umar Cheema 



October 15, 2010 



APPEAL BRIEF 



Robert M. Bain, Reg. No. 36,736 
SENNIGER POWERS LLP 
100 North Broadway, 17th Floor 
St. Louis, Missouri 63102 
(314)345-7000 



TABLE OF CONTENTS 



TABLE OF AUTHORITIES iv 

I. REAL PARTY IN INTEREST 1 

II. RELATED APPEALS AND INTERFERENCES 1 

III. STATUS OF CLAIMS 1 

IV. STATUS OF AMENDMENTS 2 

V. SUMMARY OF CLAIMED SUBJECT MATTER 2 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 5 

VII. ARGUMENT 5 

A. Claims 1-21 and 24 are nonobvious under 35 U.S.C. §1 03(a) 

and patentable over Reed et al. U.S. Patent Application 

Publication No. 2002/0095454, in view of Lemke, U.S. Patent 

Application Publication No. 2005/0086306, and further in view of 

Border et al., U.S. Patent Application Publication No. 

2002/0071436 5 

i. Appellants have successfully established conception of 
the invention prior to January 2, 2003 and due diligence from 

this date to the filing date of November 21 , 2003 5 

a. Lemke is not valid prior art 7 

ii. The Office conceded that Appellants have successfully 
overcome Lemke 7 

iii. The cited art fails to teach or suggest each and every 

feature of claims 1-21 and 24 8 



ii 



VIII. CONCLUSION 9 

IX. CLAIMS APPENDIX 11 

X. EVIDENCE APPENDIX 16 

XI. RELATED PROCEEDINGS APPENDIX 17 



iii 



TABLE OF AUTHORITIES 



REFERENCES 

37 C.F.R §1.131 5, 6,8 

MPEP 715.07 7 

CASES 

Mergenthaler v. Scudder, 1897 CD. 724, 81 O.G. 1417 (D.C. Cir. 1897) 7 

FonarCorp. v. General Electric Co., 902 F.Supp. 330, 348 (E.D. NY 1995) 7 



iv 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Application of David Paul Limont et al. Art Unit 2444 

Serial No. 10/719,866 
Filed November 21, 2003 
Confirmation No. 3063 

For METHOD AND COMPUTER PROGRAM PRODUCT TO PROVIDE SYNC 

NOTIFICATIONS TO CLIENT DEVICES 
Examiner Umar Cheema 

October 15, 2010 
APPEAL BRIEF 

This is an appeal from the final rejection of the claims of the above-referenced 
application made in the final Office action dated May 13, 2010. A Notice of Appeal was 
filed on August 13, 2010. 

The appeal brief fee in the amount of $540.00 is submitted herewith. 

I. REAL PARTY IN INTEREST 

The real party in interest in connection with the present appeal is Microsoft 
Corporation of One Microsoft Way, Redmond, Washington, 98052, a corporation of the 
state of Washington, owner of 100 percent interest in the pending application and the 
assignee of record. 

II. RELATED APPEALS AND INTERFERENCES 

Appellants are unaware of any pending appeals, interferences, or judicial 
proceedings that may be related to, directly affect or be directly affected by, or have a 
bearing on, the Board's decision in the pending appeal. 

III. STATUS OF CLAIMS 

Claims 1-21 and 24, as set forth in the Claims Appendix, are currently pending in 
the application for consideration. Claims 22 and 23 have been canceled. 
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Claims 1-21 and 24 stand rejected. The rejection of each of these claims is 
being appealed. 

IV. STATUS OF AMENDMENTS 

No amendments have been filed subsequent to the final rejection made in the 
Final Office Action dated May 13, 2010. All amendments have been entered. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The following summary correlates claim elements to embodiments described in 
the application specification but does not in any manner limit claim interpretation. 
Rather, the following summary is provided only to facilitate the Board's understanding of 
the subject matter of this appeal. 

Aspects of the present application relate to computer-based notification systems 
and, more particularly, methods and systems to notify a user of events of interest to the 
user. A parameter (e.g. a syncGUID) is stored in a configuration file for a user/device 
(reference character 204, for example) and indicates whether it is up to date or not from 
the perspective of a server 202. When the server 202 receives notification of an event 
of interest, the server 202 refers to this stored parameter and compares it to a last 
known value of the parameter for the client device 204 to decide whether or not the 
device needs to be prompted to sync. If the last known value is the same as the stored 
parameter, and the current time is found to be greater than a timeout value, the server 
202 sends the sync notification to the client 204 and resets the timeout value. If this is 
not the case (i.e., the stored parameter is not equal to the last known value), the last 
known value is updated with the value of the stored parameter and a sync notification is 
sent, while the timeout value is set to a new value as well. Claims 1,11, and 24 are the 
independent claims involved in the appeal. 

Independent claim 1 is directed to a method to provide sync notification to a 
client device 204. See application at FIGS. 3-4 and paragraphs 27-31 . A server 202 or 
module determines or otherwise receives notification of an event of interest. The event 
of interest can include, but is not limited to, an incoming email, a new calendar item, a 
weather update, an instant message, and so on. In response to the notification, a 
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device/configuration file is retrieved for the client device 204 to determine a state of the 
client device 204 (step 300). The state indicates whether or not the client device 204 
has outstanding sync notifications (e.g., outstanding email that is yet to be delivered 
from an Exchange Server to an email client). The device file contains a syncGUID for 
the device, which is updated after each successful device synchronization of the client 
device 204 with the server 202. The server 202 also maintains an in-memory table of 
'last-known' syncGUIDs for each device. This last-known syncGUID is called a 
trackingGUID. See Application at FIG. 3 and paragraphs 27 and 28. 

The server 202 determines the state of the client device 204 by determining if the 
user has retrieved the message and, if not, the server compares the trackingGUID to 
the syncGUID. If the trackingGUID is not equal to the syncGUID (i.e., a pending 
notification exists), then: a) the trackingGUID is set equal to the syncGUID (step 302), 
b) a time is set equal to a currrent time plus a predetermined value (step 304), and c) 
the pending notification is sent (step 306). Any value is possible, and may be based on 
the specific application. By way of example, one to two hours is sufficient for a network 
providing weather information, while a value of fifteen minutes is necessary for email 
applications. See Application at FIG. 3 and paragraph 29. 

On the other hand, if the trackingGUID is equal to the syncGUID and the current 
time is less than or equal to the timeout value, no notification is sent. But if the current 
time is greater than the timeout, the notification is sent (step 308) when the 
trackingGUID and syncGUID are equal. See Application at FIG. 3 and paragraph 30. 

In accordance with another aspect of the application, independent claim 11 is 
directed to at least one computer readable storage medium having computer executable 
instructions for providing a sync notification to a client device 204. See Application at 
FIGS. 1 and 3-4, paragraphs 19, 24, 27-31. Notification of an event of interest is 
received. In response to the notification, a device/configuration file is retrieved for the 
client device 204 to determine a state of the client device 204 (step 300). The state 
indicates whether or not the client device 204 has outstanding sync notifications. The 
device file contains a syncGUID for the device, which is updated after each successful 
device synchronization of the client device 204 with the server 202. An in-memory table 
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of 'last-known' syncGUIDs, called trackingGUIDs, for each device is maintained. See 
Application at FIG. 3 and paragraphs 27 and 28. 

The state of the client device 204 is determined by determining if the user has 
retrieved the message and, if not, comparing the trackingGUID to the syncGUID. If the 
trackingGUID is equal to the syncGUID (i.e., no pending notification exists prior to 
receipt of the received notification) and the current time is greater than the timeout, then 
the pending notification is sent (step 308). 

If the trackingGUID is equal to the syncGUID and the current time is less than or 
equal to the timeout value, no notification is sent. See Application at FIG. 3 and 
paragraph 30. 

Independent claim 24 involves a method of providing sync notifications to a client 
device 204. See application at FIGS. 3-4 and paragraphs 27-31. A notification of an 
event of interest is received or otherwise determined. In response to the notification, a 
device/configuration file is retrieved for the client device 204 to determine a state of the 
client device (step 300). The state indicates whether or not the client device 204 has 
outstanding sync notifications. The device file contains a syncGUID for the device 204, 
which is updated after each successful device synchronization of the client device with 
the server 202. The server 202 also maintains an in-memory table of 'last-known' 
syncGUIDs for each device 204, called a trackingGUID. See Application at FIG. 3 and 
paragraphs 27 and 28. 

The server 202 determines the state of the client device 204 prior to receipt of 
the notification by comparing the trackingGUID to the syncGUID. The client device 204 
is in an up-to-date state when the trackingGUID is not equal to the syncGUID, i.e., a 
sync has been performed since a previous notification was processed. In such an 
event, the trackingGUID is set to be equal to the syncGUID and the sync notification is 
sent to the client device 204. See Application at FIG. 3 and paragraph 29. 

The client device 204 is in a pending synchronization state when the 
trackingGUID equals the syncGUID and indicates that the client device 204 has not 
performed a sync since the last notification was processed. In such a scenario, no sync 
notification is sent to the client device 204. See Application at FIG. 3 and paragraph 30. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Appellants appeal the rejection of claims 1-21 and 24 under 35 U.S.C. §1 03(a) 
as being unpatentable over Reed in view of Lemke and further in view of Border. On 
appeal, one issue is i) whether the declaration and supporting evidence filed pursuant to 
37 C.F.R. §1.131 successfully established conception coupled with diligence to 
overcome the obviousness rejection. In this regard, Appellants appeal ii) the Office's 
determination that Lemke is valid prior art. Appellants further appeal the use of Lemke 
in rejecting the claims because the Office previously conceded that Appellants had 
successfully overcome this reference. The remaining issue on appeal is iii) whether the 
claims are distinguishable over the cited references, assuming arguendo, that all the 
cited references constitute prior art 

VII. ARGUMENT 

A. Claims 1-21 and 24 are nonobvious under 35 U.S.C. 51 03(a) and patentable 
over Reed in view of Lemke and further in view of Border. 

Claims 1-21 and 24 are rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Reed et al. (U.S. Patent Application Publication No. 2002/0095454) in view of 
Lemke (U.S. Patent Application Publication No. 2005/0086306) and further in view of 
Border et al. (US Patent Application Publication No. 2002/0071436). Appellants submit 
that Lemke is invalid prior art because Appellants effectively swore behind the 
reference. Moreover, even if Lemke is valid prior art, the cited references do not teach 
or suggest each and every feature set forth in the claims. 

i. Appellants have successfully established conception of the invention 
prior to January 2, 2003 and due diligence up to the filing date of November 
21.2003. 

By way of background, Appellants submitted a §1.131 Declaration and 
supporting evidence on September 14, 2009. Appellants submit the §1 .131 Declaration 
established an invention date no later than January 2, 2003 for the instant 
application. In the subsequent Office Action dated October 29, 2009, the Office 
removed the previously applied Thomas references (U.S. Patent Application Publication 
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No. 2003/0004917 and EP 1 271 320), which claim priority from U.S. Patent No. 
6,952,708) and reintroduced Lemke. Because the Office set forth a new basis for 
rejecting the instant claims, the Office essentially indicated that the Declaration proved 
effective in removing the Thomas references. 

In the latest Office Action dated May 13, 2010, the Office incorrectly states that 
Appellants attempted to provide evidence demonstrating reduction to practice (Office 
Action of May 13, 2010, page 2, section 3) and failed to do so (Office Action of May 13, 
2010, page 3, section 7). The Office further reminded Appellants of the proof required to 
establish reduction to practice (Office Action of May 13, 2010, page 3, section 5). Under 
37 C.F.R §1.1 31(b), "The showing of facts shall be such, in character and weight, as to 
establish reduction to practice prior to the effective date of the reference, or conception 
of the invention prior to the effective date of the reference coupled with due 
diligence from prior to said date to a subsequent reduction to practice or to the filing 
of the application" (emphasis added). 

Appellants, on the other hand, clearly indicated (§1.131 Declaration and Exhibits 
filed September 14, 2009) that the submitted exhibits were directed toward establishing 
conception prior to January 2, 2003 (§1 .131 Declaration, sections 3-10) coupled with due 
diligence from before the effective date of the reference in preparing and filing the instant 
patent application (§1.131 Declaration, sections 11-16). The Office's reading of the 
Appellants' submissions is strictly limited to only one possible approach of establishing 
prior invention, and is hence consistently erroneous. 

The Office also argues that relying on pseudo code and an algorithm does not 
make the invention clear to one of ordinary skill. Appellants submit that one of ordinary 
skill in the computing and programming fields clearly understands descriptive algorithms 
and pseudo code, especially when read in the context of the entire disclosure of Exhibit A, 
describe a programming algorithm in informal, natural language that may be structured to 
apply to one or more programming languages. Appellants submit that proof of execution 
of machine-executable code on a machine or the like is not absolutely required to 



6 



establish that a software invention has been conceived. 1 The Declaration and 
Supporting Evidence satisfy the standard set forth in MPEP 715.07 and the case law. 
As required by MPEP 715.07, the Declaration and Supporting Evidence have shown more 
than mere general allegation; they substantiate concrete results of conception of 
embodiments of the invention. MPEP 715.07(III)(C) recites in part that "Conception is 
the mental part of the inventive act, but it must be capable of proof, as by drawings, 
complete disclosure to another person, etc. In Mergenthaler v. Scudder, 1897 CD. 
724, 81 O.G. 1417 (D.C. Cir. 1897), it was established that conception is more than a 
mere vague idea of how to solve a problem; the means themselves and their interaction 
must be comprehended also." In this case, Appellants have elaborately detailed how 
the invention disclosure of Exhibit A details elements that map to each and every 
element of the pending independent claims, including their interactions. 

The Office further argues that Exhibits C-G are email copies which do not disclose 
limitations of Appellants' claimed invention (Office Action of May 13, 2010, page 3, section 
6). Appellants submit that as described in the Declaration, Exhibits C-G are directed 
toward showing Appellants' due diligence in preparing and filing the instant patent 
application, not towards establishing conception (or reduction to practice). 

The Office's analysis of the Appellants' submissions of September 14, 2009 is 
inaccurate and provides erroneous grounds of rejection. Further, Appellants submit that 
the fact that the Office reacted to these submissions by removing the Thomas references 
is indicative of Appellants' successful establishment of a conception date no later than 
January 2, 2003 coupled with Appellants' diligence in filing the present patent application. 

a. Lemke is not valid prior art. 

Lemke has a filing date of March 14, 2003. As discussed above, Appellants 
established that they conceived of their claimed invention before January 2, 2003 and 
proceeded diligently with filing the instant application. This proved effective in causing 
the Office to remove the previously relied upon Thomas references. Because the 
Lemke reference likewise has an effective filing date later than January 2, 2003, it does 

1 See Fonar Corp. v. General Electric Co., 902 F.Supp. 330, 348 (E.D. NY 1995) (noting that reduction to 
practice of software merely involves writing software routines). In this instance, Appellants wrote software 
routines, as evidenced by the pseudo code, before the effective date of the reference. 
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not qualify as prior art under any subsection of 35. U.S.C. §102, and, thus, cannot be 
used as a basis of rejection of the pending claims. 

ii. The Office conceded that Appellants have successfully overcome 
Lemke based on the Office's prosecution history. 

Appellants submit, based on the actions by the Office in prosecuting the instant 
application, that the Office conceded Appellants have already distinguished the claims 
over Lemke. 

The Office originally applied Reed/Border/Lemke in the first Office Action (dated 
June 29, 2007) as well as the second Office Action (dated February 20, 2008). 
Appellants' representative conducted an interview with Examiner Cheema on August 
25, 2008 during which Appellants' representative discussed the differences between the 
claims as presented in Amendment B (filed April 11, 2008) and the cited art. In the 
Office Action (dated September 10, 2008) immediately following the interview, the Office 
removed Lemke and introduced Thomas (U.S. Patent Application Publication No. 
2003/0004917) in its place. The new grounds of rejection presented in the September 
10, 2008 Office Action substantiate Appellants' position that the Office agreed the 
combination of Reed/Border/Lemke did not disclose all the claimed features as 
previously argued by the Office. 

In the Final Office Action dated April 15, 2009, the Office persisted with the 
combination of Reed/Thomas/Border/Thomas in rejecting the claims as presented in 
Amendment C (filed December 18, 2008), which indicated to Appellants that Lemke was 
still deficient. Appellants then filed a §1.131 Declaration and a Response without further 
claim amendments. 

Since no further amendments have been made, and since the prosecution 
history of the present application clearly indicates that the Office did not consider Lemke 
to cure the deficiencies of the other cited references with respect to the current claims, it 
is contradictory and improper for Lemke to be cited anew for rejecting the pending 
claims. 

The Office now contends (Final Office Action of May 13, 2010, page 2, paragraph 
2) that the Thomas references were replaced by the Lemke reference since it "taught or 
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suggested the Appellants' invention better." Appellants submit that even if one 
assumes that Lemke is indeed valid prior art, it is unreasonable to reintroduce 
references once amendments and/or arguments have previously overcome those 
references, particularly when no claim amendments have since been made. 

iii. The cited art fails to teach or suggest each and every feature of claims 
1-21 and 24. 

Claims 1-21 and 24 are rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Reed in view of Lemke and further in view of Border. Appellants submit that the 
applied references, alone or in combination, do not render these claims unpatentable. 

Reed teaches a system for transferring data, metadata and methods from a 
provider computer to a consumer computer through a communications network. Border 
discloses a system for a proxy architecture. As correctly stated by the Office, neither 
Reed nor Border, separately or together, disclose every feature set forth in the claims. 
For example, the Office acknowledges that these two references fail to disclose "setting 
the trackingGUID equal to the syncGUID" (Office action of May 13, 2010, page 5, 
section 10); and "sending the sync notification to the client device if the current time is 
less than the timeout, said timeout being used to determine the maximum time between 
sync notifications; and sending the sync notification to the client device if the current 
time is greater than timeout" (Office action of May 13, 2010, pages 5 and 6, section 10). 

Lemke discloses a system for managing the transfer of messages of a network 
via background delivery (Lemke, abstract) and teaches setting composite bandwidth 
values within an interval. (Lemke, page 8, paragraph [0121]). In contrast, Appellants' 
claims recite that the device is up-to-date when, to the server's knowledge, the device is 
completely in sync with the server with the possible exception of the event which just 
triggered a sync notification (Specification, [0027]). Significantly, the device is pending 
synchronization when a sync notification has been sent to the device telling it to sync 
with the server, but the device has not yet performed synchronization 
(Specification, [0027]). Lemke (Paragraph [0131], cited in Office Action of May 13, 
2010, page 6, section 11) merely discloses comparing cumulative data demands (C(t) 
and D(t)) of two different nodes (nodes C and D) with respect to a third node (node B), 
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and setting a composite bandwidth value accordingly. Appellants' syncGUID, on the 
other hand, is used to designate a parameter that provides a representation of the state 
of the device. Moreover, it provides an indication of whether an event of interest 
renders the device no longer up to date from the perspective of the server or whether an 
event of interest occurs and the server has not been contacted by the device for a 
certain period of time. (Specification, [0027]). 

As discussed above, not only is Lemke unable to cure the deficiencies of the 
other applied references based on previous arguments/amendments accepted by the 
Office, but Lemke is invalid prior art by virtue of the Appellants having established a 
priority date no later than January 2, 2003. 

For all these reasons, the 35 U.S.C. § 103 rejection of these claims is improper 
and should be withdrawn. 

VIII. CONCLUSION 

For at least the reasons stated above, Appellants respectfully request that the 
Office's rejections be reversed and that claims 1-21 and 24 be allowed. 



Respectfully submitted, 

/Robert M. Bain/ 

Robert M. Bain, Reg. No. 36,736 
SENNIGER POWERS LLP 
100 North Broadway, 17th Floor 
St. Louis, Missouri 63102 
(314)345-7000 
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IX. CLAIMS APPENDIX 



Claim 1 (previously presented): A method to provide a sync notification to a client 
device comprising the steps of: 

receiving notification that an event of interest has been received; 
in response to receiving the notification, determining a state of the client device, 
said state indicating whether or not the client device has outstanding sync notifications, 
said state being determined based on a trackingGUID and a syncGUID; 

if the state of the client device indicates that the client device has no outstanding 
sync notifications prior to the receipt the received notification: 

setting trackingGUID equal to the syncGUID, wherein the syncGUID is 
updated after each successful device synchronization of the client device; 

setting a timeout equal to a current time plus a predetermined value; and 
sending the sync notification to the client device; and 
if the state of the client device indicates that the client device has at least one 
outstanding sync notification: 

not sending the sync notification to the client device if the current time is 
less than the timeout, said timeout being used to determine the maximum time 
between sync notifications; and 

sending the sync notification to the client device if the current time is 
greater than the timeout. 

Claim 2 (original): The method of claim 1 further comprising the step of sending the 
sync notification to the client device if the trackingGUID equals the syncGUID and the 
current time is greater than the timeout. 

Claim 3 (original): The method of claim 2 further comprising the step of setting the 
timeout equal to the current time plus the predetermined value. 
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Claim 4 (original): The method of claim 1 further comprising the step of receiving a 
device/user configuration file having at least one of the syncGUID and the 
trackingGUID. 

Claim 5 (original): The method of claim 4 further comprising the step of reading the at 
least one of the syncGUID and the trackingGUID from the device/user configuration file. 

Claim 6 (original): The method of claim 1 wherein the predetermined value is fifteen 
minutes. 

Claim 7 (original): The method of claim 1 wherein the predetermined value is in the 
range of one to two hours. 

Claim 8 (original): The method of claim 1 wherein the step of sending the sync 
notification comprises sending the sync notification using the SMTP (simple mail 
transfer protocol) protocol. 

Claim 9 (original): The method of claim 1 further comprising the step of determining if 
the client device has received the event of interest. 

Claim 10 (original): The method of claim 1 wherein the step of receiving notification that 
an event of interest has been received comprises the step of receiving a trigger event. 

Claim 11 (previously presented): At least one computer readable storage medium 
having computer executable instructions for providing a sync notification to a client 
device, the computer executable instructions performing the steps of: 

receiving notification that an event of interest has been received; 

in response to receiving the notification, determining a state of the client device, 
said state indicating whether or not the device has outstanding sync notifications prior to 
the receipt the received notification, said state being determined based on a 
trackingGUID and a syncGUID; 
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determining if a current time is less than a timeout set based on the confidence 
level of the network wherein the timeout indicates how long to wait to retry sending the 
notification to the device; 

sending the sync notification to the client device if the state of the client device 
indicates that the client device has at least one outstanding sync notification prior to the 
receipt the received notification and the current time is not less than a timeout; and 

not sending the sync notification to the client device if the state of the client 
device indicates that the client device has at least one outstanding sync notification prior 
to the receipt the received notification and the current time is less than a timeout. 

Claim 12 (previously presented): The at least one computer readable storage medium 
of claim 11 having further computer executable instructions for performing the steps 
comprising: 

if the trackingGUID does not equal the syncGUID: 

setting the trackingGUID equal to the syncGUID; 

setting a timeout equal to the current time plus a predetermined value; and 
sending the sync notification to the client device. 

Claim 13 (previously presented): The at least one computer readable storage medium 
of claim 12 having further computer executable instructions for performing the steps 
comprising determining if the trackingGUID equals the syncGUID. 

Claim 14 (previously presented): The at least one computer readable storage medium 
of claim 13 having further computer executable instructions for performing the step 
comprising setting the timeout equal to the current time plus the predetermined value. 

Claim 15 (previously presented): The at least one computer readable storage medium 
of claim 14 wherein the predetermined value is fifteen minutes. 

Claim 16 (previously presented): The at least one computer readable storage medium 
of claim 14 wherein the predetermined value is in the range of one to two hours. 
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Claim 17 (previously presented): The at least one computer readable storage medium 
of claim 11 having further computer executable instructions for performing the step 
comprising receiving a device/user configuration file having at least one of the 
syncGUID and the trackingGUID. 

Claim 18 (previously presented): The at least one computer readable storage medium 
of claim 17 having further computer executable instructions for performing the step 
comprising reading the at least one of the syncGUID and the trackingGUID from the 
device/user configuration file. 

Claim 19 (previously presented): The at least one computer readable storage medium 
of claim 11 wherein the step of sending the sync notification comprises sending the 
sync notification using the SMTP (simple mail transfer protocol) protocol. 

Claim 20 (previously presented): The at least one computer readable storage medium 
of claim 11 having further computer executable instructions for performing the step 
comprising determining if the client device has received the event of interest. 

Claim 21 (previously presented): The at least one computer readable storage medium 
of claim 1 1 wherein the step of receiving notification that an event of interest has been 
received comprises the step of receiving a trigger event. 

Claim 22 (canceled). 

Claim 23 (canceled). 

Claim 24 (previously presented): A method to provide a sync notification to a client 
device comprising the steps of: 

receiving a notification that an event of interest has occurred; 
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in response to the notification, retrieving a device/configuration file of the client 
device, said device/configuration file including a syncGUID and a trackingGUID, said 
syncGUID being updated after each successful device synchronization of the client 
device for indicating a state of the client device, and said trackingGUID being set to 
equal the last known syncGUID for the client device; 

determining the state of the client device prior to receipt of the received 
notification based on the trackingGUID, wherein the client device is in an up-to-date 
state when the trackingGUID does not equal the syncGUID indicating the client device 
has performed a sync since a previous notification was processed and wherein the 
client device is in a pending synchronization state when the trackingGUID equals the 
syncGUID indicating the client device has not performed a sync since the previous 
notification was processed; 

sending the sync notification to the client device and re-setting the trackingGUID 
to equal the syncGUID when the determined state of the client device prior to the 
receipt of the received notification is the up-to-date state; and 

not sending the sync notification to the client device when the determined state of 
the client device prior to the receipt of the received notification is the pending 
synchronization state. 
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EVIDENCE APPENDIX 

None. 



RELATED PROCEEDINGS APPENDIX 

None. 
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